A service is a system that a consumer of the service interacts with through a set of coarse-grained messages. A service oriented application may be composed of one or more services. Each of these application services typically contains a set of entities. Entities, in general, encapsulate data and provide a rich programming model for creating, reading, updating and deleting the data owned by the service.
Services typically contain private data and public data. The private data is encapsulated in an internal entity so that, within the service, the programming model provides access to all of the data and associations contained in the internal entity, but external to the service, the internal entity is not exposed through the service interface. However, public data is encapsulated in a publicly available entity which is available to consumers of the service.
It is common for a consumer of a service to access data of an entity owned by the service. One prior way for enabling this had the consumer directly access the owning service's data store. However, direct access to the owning service's data store requires the consumer of the data to have knowledge of the technology and table structure used by the owning service to store data in its data store. Similarly, such direct access allows the consumer to potentially view and change private data within the service. This is problematic for a number of reasons, and is discouraged in applications that honor the publicly known tenets of service orientation. These are set out in an article by Don Box entitled Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo, MSDN Magazine, January 2004. Basically, allowing an external service or client to bind directly to the owning service's data (either by access to the service's private entities or by directly accessing the data store which the service stores its data in) is a technique that compromises data integrity, the autonomy, and the explicit boundaries of the service in a service oriented environment. Instead, all communication with a service should occur using standardized message exchange.
There are a variety of message exchange patterns which may occur in a service oriented environment. One of these patterns is out-only messaging. In this pattern multiple services, referred to as subscribers, subscribe to certain notifications from a given service, referred to as a publisher. At the appropriate times, that service then sends these notification messages to all interested subscribers. Uses for this message exchange pattern include synchronization subsystems, auditing subsystems, various business logic, and many others. The difficulty with utilizing this message exchange pattern today is the publisher must ensure that all appropriate out-only messages are sent, or risk corrupting or confusing any of the subscribers or subsystems using out-only messaging.
The out-only messaging pattern is very similar to the concept of eventing in many existing programming languages. Most application frameworks currently provide a way for business logic to subscribe to create, update and delete events within a service and perform local processing logic when they occur. However, when a separate service wishes to be notified about these create update and delete events, it must subscribe and be notified via messaging. One way a service subscribes and is notified of these events is defined in the WS-Eventing specification. This specification does not provide guidance on how to ensure that all internal events are properly sent as external out-only messages however
When a service holds data from another service, it becomes very important to synchronize that data with associated data in a local data store. Synchronization is the process through which data is replicated to a local data store and maintained by applying changes made to the owning service's data store to the consumer's data store. For instance, a consumer may wish to periodically synchronize data from the owning service's data store to its own local data store.